Btrfs 相关

extent

它是用于构成 chunk 的，由数个连续 block 组成的逻辑空间。它的语义通常是「数个 block 组成的连续的逻辑空间」。

extent 是存储数据的最小的逻辑单位 (存储数据的最小的物理单位是 block)，只能作为整体被不同对象共享 (比如 reflink)，不能存储不同对象的数据 (比如一个 extent 不能存储两个文件的数据)。extent 的大小由 btrfs 决定，最小为 4K，一旦确定就不可被更改。

比如，有一个 1M 大小的文件使用了 1 个 1M 大小的 extent，那么再向这个文件写入 512K 的新数据之后，这个文件最终会使用 1M 大小的 extent 和 512K 大小的 extent 一共两个 extent。只有当 1M 大小的 extent 中的数据被写往别处时，这个旧的 1M 大小的 extent 才被释放。如果修改了 1M extent 中的一部分数据，可能导致这个 1M extent 分裂成三份 (修改位置之前的、修改位置的和修改位置之后的数据)；或者 btrfs 读出整个 extent 的数据，修改完后将这一整个 extent 覆写会原位置。总之，extent 的管理策略极为复杂，用户不需要关心。

如果某个文件被 btrfs 压缩后存储在硬盘上，那么该文件被压缩的 extent 的最大大小是 128K。这是因为 btrfs 在读取被压缩的数据中的某个 block 时，必须先解压完整的 extent，设置过大的 extent 会严重影响被压缩的文件的读写性能。为了避免这个问题，btrfs 取了一个折中的 128K 大小作为被压缩的数据的最大的 extent 的大小。

chunk (block group)

btrfs 中有三种 chunk: data, metadata 和 system。chunk 是由数个 extent 组成的一个逻辑空间。chunk 和 block group 有时可以互换使用。它的语义通常是「被 btrfs 动态分配，用于存储 data, metadata 或 system 数据的空间」。extent 最终会被写入到 chunk 中。

这三类 chunk 的大小只能在创建文件系统时修改。通常，data chunk 的大小总是 1G。在文件系统小于 50G 时，metadata chunk 大小是 256M；在文件系统大小为 50G 及以上时，metadata chunk 大小是 1G。文档里只说 system chunk 的大小是数 M，经测试，在 4*8T raid10 的文件系统中，system chunk 大小是 32M。

btrfs 与 zfs 类似，也支持异常数据自动修复。与 zfs 相同，btrfs 文件系统中，只有在数据有副本，比如使用 dup, raid10, raid1c3 等存储模式；或者使用 raid5/6 这种可以恢复文件的存储模式时，btrfs 才会自动修复异常的数据。

如果数据没有副本，或者没有使用可以修复数据的存储模式，则 btrfs 与 zfs 相同，只能检测到数据异常，但无法修复。

btrfs 的挂载参数按影响范围可以划分为针对全局的参数和针对子卷 subvolume 的参数。

btrfs 的全局挂载参数由首个被挂载的子卷决定，如果有些必须的挂载参数没有被用户指定，那就使用默认值。并且，后续挂载其他子卷时使用的全局参数全部不生效。

此外，需要注意:

• 不能单独为某个子卷关闭 CoW 特性，因为 nodatacow 是个全局挂载参数，但可以通过 chattr +C <path> 命令对某个文件或目录关闭 CoW 特性 (作用于目录时，目录内已有文件不受影响，新文件关闭 CoW 特性)

修改子卷使用的压缩算法之后，可以使用 btrfs filesystem defragment -r -v -c<compress-alg> <mount-point> 开始对子卷的挂载点进行碎片整理， -c 参数会让所有文件在碎片整理过程中被新的压缩算法重新压缩。

注: -r 递归目录，但不会递归地进入挂载点或子卷； -v 输出详细过程； -c 指定压缩算法。

但是需要注意，在对建有快照的子卷上进行碎片整理可能会触发 CoW 导致没有变更的 extent 也被重新分配了空间，而由于快照的存在，旧 extent 占有的空间也不会被释放，从而导致空间使用率增加。

使用 CoW 特性的文件系统会比非 CoW 文件系统更容易产生碎片。

因为，在使用 CoW 特性时，当一个数据被从硬盘上读出，并写回硬盘，CoW 文件系统的每一次都会将这些数据写入到硬盘上的另一个位置，而不是数据原先在硬盘上所处的位置。

所以，使用一段时间后，extent 可能被分配得过于离散，或 extent 被打散到较小的空间中，这都会增加硬盘寻道消耗的时间。

碎片整理 btrfs filesystem defragment [options] <file>|<dir> [<file>|<dir>…] 可以将被碎片化存储 (分布在多个、多处的 extent 中) 的数据，重新读到内存中，然后尽可能地将他们一起写入到硬盘上。

defragment 优化的是 extent 的分布和分配，它将被打散的 extent 重新组合成一个较大的 extent，并使文件的所有 extent 在硬盘上的位置尽可能地近。所以 defragment 会让数据所在的位置更加连续，从而减少硬盘寻道消耗的时间。

这个命令有一个重要的参数 -t (默认值 32M)，它向碎片整理操作传递了一个描述 extent 大小的值。表示，大小低于该值的 extent 会被碎片整理程序考虑与该文件的其他 extent 合并并重新写入。多数时候，保持默认即可。

碎片整理之后，可用空间有可能不连续，此时可以进一步用 balance 重新排列数据，从而让可用空间尽量连续。

btrfs balance 是一种获取 btrfs 文件系统上的所有数据和元数据，然后通过分配器算法进行传递，最后将其重新写入磁盘上的不同位置的操作。它最初为多设备文件系统设计，目的是让数据在在设备间更均匀地分布。所以这个操作在将新设备添加到几乎已满的文件系统时尤其有用。

balance 优化的是 chunk 的分布和分配，它将未被充分使用的 chunk 中的数据合并在有空余空间的 chunk 中，并回收腾出的 chunk，并让 chunk 的分布尽量连续。所以在 chunk 数量不足时，它可以回收一些未被充分使用的 chunk，从而让 btrfs 拥有更多可分配的空间；也可以在 chunk 被分配得过于离散时，重新调整 chunk 的分布，使其更加连续以减少硬盘寻道消耗的时间。

这个功能还有一些其它作用:

• 可以用于重建 raid。在一个使用了 raid1 的 btrfs 上，如果有一个新硬盘替换了已经损坏的硬盘，那么在这个新硬盘被加入文件系统之后，新硬盘中没有数据。balance 操作会让 btrfs 重建应该存在于新硬盘上的数据
• 可以改变 data 或者 metadata 的存储模式，比如让将文件 data 部分在硬盘上存储两份 btrfs balance start -dconvert=dup <path> (metadata 的默认模式就是 dup ，即默认在硬盘上存两份相同的 metadata)

在 btrfs 3.14 之后，有时需要使用 balance 操作来修复由于 chunk 用尽导致无法给 metadata 分配 chunk 从而出现文件系统已满的问题。这里要注意只 balance data chunk，不要动 metadata chunk，因为元数据越是集中存放，将来就越可能需要分配新的 chunk，就越有可能遇到没 chunk 可以分配给 data 的情况。

有一个指标可以用来参考是否需要 balance:

# btrfs filesystem df /mnt/mp_storage0
Data, RAID10: total=4.38TiB, used=4.37TiB  # total 指已分配的空间，used 指当前用了多少已分配的空间
System, RAID10: total=16.00MiB, used=464.00KiB
Metadata, RAID10: total=7.50GiB, used=7.01GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

used/total 如果得出的百分比过低，则有可能出现 chunk 中有大量未使用空间的情况。而这种情况下 defragment 操作没有用，defragment 只影响文件的连续性，不影响 chunk 分配。所以此时最好使用 balance 把未使用的 chunk 空间回收一下。